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(54) Privacy of data on a computer platform 

(57) A computer platform has a trust mechanism 
adapted to assure third parties interacting with the com- 
puter platform that the computer platform operates ac- 
cording to an indicated specification and a trusted exe- 
cution area for execution of operations upon data. The 
trust mechanism guarantees the trusted status of the 



trusted execution area. In respect of the trusted execu- 
tion area, privacy of third party data, or of audit of proc- 
esses carried out on third party data, or of both, can be 
assured by the trust mechanism. This can in one ar- 
rangement be achieved by use of an audit data portal 
to provide controlled access to audit data. 
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Description 

BACKGROUND OF THE INVENTION 
Field of the Invention 

[0001] This invention relates to a method and appa- 
ratus that allow access to data on a computer platform 
and audit of processes acting on data on a computer 
platform to be controlled. It is particularly relevant to 
control by the owner of the data. 

Description of Related Art 

[0002] A previous patent application in the name of 
the present applicant, Hewlett-Packard Company, US 
Patent Application No. 09/920554, filed on August 1 , 
2001 and entitled "Performance of a Service on a Com- 
puting Platform", (published as US02-0023212) and 
which is incorporated herein by reference, describes op- 
erations on a computing platform that has trusted com- 
partments. That patent application is itself based on up- 
on the applicant's WO 00/48063, entitled "Trusted Com- 
puting Platform" which discloses a trusted computing 
platform method and apparatus, which application is al- 
so incorporated herein by reference. The computer plat- 
form in the former application contains potentially sev- 
eral trusted compartments, which can operate at differ- 
ent levels of trust. Trusted compartments have the prop- 
erties of conventional software compartments, referred 
to in the former application, in that they isolate the proc- 
ess inside the compartment from processes in other 
compartments, and control the access of the processes 
to platform resources. Trusted compartments have ad- 
ditional properties, in that they are able to record and 
provide proof of the execution of a process. They also 
provide privacy controls for data by checking that data 
is being used only for permitted purposes. The walls of 
some compartments are constructed from dedicated 
hardware, while the walls of other compartments are 
built using software that executes on the main computer 
platform processor. 

[0003] The trusted computing platform (TCP) applica- 
tion referred to above discloses hardware which allows 
an integrity metric of a computing platform including a 
trusted platform module (TPM) or trusted device (TD) to 
be returned to a requestor at the time that a service re- 
quested by the requestor was carried out. As well as the 
integrity metric, evidence is provided that the service 
was carried out in accordance with required levels of 
trust. 

[0004] Owners of third party data - who may be re- 
questors of services as indicated above, or may be pro- 
viders of content - may require still greater levels of pri- 
vacy. In particular, they may wish to minimise any risk 
that their valuable data may lose economic value by be- 
ing exposed to others, or that the third party's privacy 
may be compromised (for example, by exposure of 



medical data to another party). These concerns could 
apply to the user of a trusted computing platform, or 
even to the administrator of a trusted computing plat- 
form. The privileges normally held by an administrator 
5 are such that their level of control over a platform is the 
maximum level available, and typically greater than that 
possessed by a user. 

BRIEF SUMMARY OF THE INVENTION 

10 

[0005] According to a first aspect of the invention 
there is provided a computer platform having: a trust 
mechanism adapted to assure third parties interacting 
with the computer platform that the computer platform 

15 operates according to an indicated specification; and a 
trusted execution area for execution of operations upon 
data, wherein a trusted status of the trusted execution 
area is assured by the trust mechanism, and having no 
uncontrolled communication paths with any other part 

20 of the computer platform; whereby third party data in a 
memory of the trusted execution area has access re- 
strictions to parties other than the third party, and the 
trust mechanism is adapted to indicate to the third party 
an attempt to access the third party data which is incon- 

25 sistent with the access restrictions. 

[0006] According to a second aspect of the invention 
there is provided a computer platform having: a trust 
mechanism adapted to assure third parties interacting 
with the computer platform that the computer platform 

30 operates according to an indicated specification; a trust- 
ed execution area for execution of operations upon data, 
wherein a trusted status of the trusted execution area is 
assured by the trust mechanism, and having no uncon- 
trolled communication paths with any other part of the 

35 computer platform; an trusted audit mechanism for ob- 
taining an audit record of operations upon data in the 
trusted execution area and for controlling access to the 
audit record, wherein a trusted status of the trusted audit 
mechanism is assured by the trust mechanism. 

40 [0007] According to a third aspect of the invention 
there is provided an audit data portal for a trusted com- 
puting platform adapted to assure third parties interact- 
ing with the computing platform that the computer plat- 
form operates according to an indicated specification is 

45 operable to contain information that is sufficient and/or 
required for the audit of a trusted process executing on 
the trusted computing platform whose reliable execution 
is assured by the trusted computing platform. 
[0008] According to a fourth aspect of the invention 

so there is provided an audit data portal for a trusted com- 
puting platform adapted to assure third parties interact- 
ing with the computing platform that the computer plat- 
form operates according to an indicated specification is 
operable to control access to information that is suffi- 

55 cient and/or required for the audit of a trusted process 
executing on the trusted computing platform whose re- 
liable execution is assured by the trusted computing 
platform. 
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[0009] In respect of the third and fourth aspects of the 
invention, the audit data is thus controlled so that access 
can be granted by the portal to advantageously maintain 
levels of information privacy required by an owner of the 
information and/or an owner of the processes using the 
information. The audit portal may advantageously re- 
strict access by an operator, owner or even administra- 
tor of the trusted computing platform to the information. 
The provision of a separate memory for audit data is also 
advantageous. 

[0010] According to a fifth aspect of the invention 
there is provided a method of executing operations on 
third party data on a computing platform, the computer 
platform having a trust mechanism adapted to assure 
third parties interacting with the computer platform that 
the computer platform operates according to an indicat- 
ed specification, the method comprising: providing the 
data, and third party access restrictions applying to the 
data, to a trusted execution area having no uncontrolled 
communication paths with any other part of the compu- 
ter platform, wherein a trusted status of the trusted ex- 
ecution area is assured by the trust mechanism; per- 
forming operations on the data in the trusted execution 
area; and the trust mechanism indicating to the third par- 
ty any attempt to access the third party data which is 
inconsistent with the access restrictions. 
[0011] According to a sixth aspect of the invention 
there is provided a method of auditing of operations on 
third party data on a computing platform, the computer 
platform having a trust mechanism adapted to assure 
third parties interacting with the computer platform that 
the computer platform operates according to an indicat- 
ed specification, the method comprising: providing the 
data to a trusted execution area having no uncontrolled 
communication paths with any other part of the compu- 
ter platform, wherein a trusted status of the trusted ex- 
ecution area is assured by the trust mechanism; per- 
forming operations on the data in the trusted execution 
area; a trusted audit mechanism obtaining an audit 
record of operations upon data in the trusted execution 
area, wherein a trusted status of the trusted audit mech- 
anism is assured by the trust mechanism; and the trust- 
ed audit mechanism providing controlled access to the 
audit record. 

[0012] All of the features disclosed herein may be 
combined with any of the above aspects in any combi- 
nation. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] In order to illustrate how the invention may be 
brought in to effect, specific embodiments will now be 
described, by way of example, with reference to the ac- 
companying drawings, in which: 

Figure 1 is a schematic diagram of a Trusted Com- 
puting Platform including an audit data portal; 



Figure 2 is a schematic diagram of a multivalued 
memory structure; 

Figure 3 is a schematic diagram of audit data portal 
5 memory; 

Figure 4 is a schematic diagram of audit data for 
one trusted process; 

io Figure 5 is a schematic diagram of a Trusted Com- 
puting Platform containing an audit data portal, an 
audit data memory, and audit viewer; 

Figure 6 is a diagram that illustrates a computing 
15 platform containing a trusted device; 

Figure 7 is a diagram which illustrates a mother- 
board including a trusted device arranged to com- 
municate with a smart card via a smart card reader 
20 and with a group of modules; 

Figure 8 is a diagram that illustrates the trusted de- 
vice of Figure 7 in more detail; 

25 Figure 9 is a flow diagram which illustrates the steps 
involved in acquiring an integrity metric of the com- 
puting platform of Figure 6; 

Figure 10 is a flow diagram which illustrates the 
30 steps involved in establishing communications be- 
tween a trusted computing platform and a remote 
platform including the trusted platform verifying its 
integrity; 

35 Figure 11 is a diagram which illustrates schemati- 
cally the logical architecture of a computing platform 
as shown in Figure 6 which employs a compart- 
mented operating system; and 

40 Figure 12 is a flow diagram illustrating the interac- 
tions between a service requestor and a computing 
platform as shown in Figure 11 ; 

DETAILED DESCRIPTION OF THE INVENTION 

45 

[001 4] Before describing embodiments of the present 
invention reference is made to a computer platform that 
has trusted compartments of a type generally suitable 
for carrying out embodiments of the present invention. 
50 a trust mechanism employing trusted devices will first 
be described more generally with reference to Figures 
6 to 1 0, and a computing platform employing such a trust 
mechanism together with a compartmented operating 
system will be described with reference to Figure 11. 
55 [0015] A trusted computing platform will be described 
with relevance to Figures 6 to 10. This description of a 
trusted computing platform describes the essential ele- 
ments of its construction, its role in providing integrity 
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metrics indicating the state of the computing platform to 
a user of that platform, and communication of such met- 
rics to a user. A "user", in this context, may be a remote 
user such as a remote computing entity (the requestor, 
in embodiments of the present invention, may fall into 
this category). A trusted computing platform is further 
described in the applicant's International Patent Appli- 
cation No. PCT/GB00/00528 entitled 'Trusted Comput- 
ing Platform" and filed on 15 February 2000, the con- 
tents of which are incorporated by reference herein. The 
skilled person will appreciate that the present invention 
does not rely for its operation on use of a trusted com- 
puting platform precisely as described below: use of 
such a trusted computing platform is one, rather than 
the only possible, manner of achieving functionality re- 
quired in the present invention. 
[0016] A trusted computing platform of the kind de- 
scribed here is a computing platform into which is incor- 
porated a physical trusted device whose function is to 
bind the identity of the platform to reliably measured da- 
ta that provides an integrity metric of the platform. The 
identity and the integrity metric are compared with ex- 
pected values provided by a trusted party (TP) that is 
prepared to vouch for the trustworthiness of the plat- 
form. If there is a match, the implication is that at least 
part of the platform is operating correctly, depending on 
the scope of the integrity metric. 
[001 7] A user verifies the correct operation of the plat- 
form before exchanging other data with the platform. A 
user does this by requesting the trusted device to pro- 
vide its identity and an integrity metric. (Optionally the 
trusted device will refuse to provide evidence of identity 
if it itself was unable to verify correct operation of the 
platform.) The user receives the proof of identity and the 
identity metric, and compares them against values 
which it believes to be true. Those proper values are 
provided by the TP or another entity that is trusted by 
the user. If data reported by the trusted device is the 
same as that provided by the TP, the user trusts the plat- 
form. This is because the user trusts the entity. The en- 
tity trusts the platform because it has previously validat- 
ed the identity and determined the proper integrity met- 
ric of the platform. 

[001 8] Once a user has established trusted operation 
of the platform, he exchanges other data with the plat- 
form. For a local user, the exchange might be by inter- 
acting with some software application running on the 
platform. For a remote user, as will generally be the case 
in embodiments of the present invention, the exchange 
might involve a secure transaction. In either case, the 
data exchanged is 'signed' by the trusted device. The 
user can then have greater confidence that data is being 
exchanged with a platform whose behaviour can be 
trusted. 

[0019] The trusted device uses cryptographic proc- 
esses but does not necessarily provide an external in- 
terface to those cryptographic processes. Also, a most 
desirable implementation would be to make the trusted 



device tamperproof, to protect secrets by making them 
inaccessible to other platform functions and provide an 
environment that is substantially immune to unauthor- 
ised modification. Since tamper-proofing is impossible, 
5 the best approximation is a trusted device that is tamper- 
resistant, or tamper-detecting. The trusted device, 
therefore, preferably consists of one physical compo- 
nent that is tamper-resistant. 

[0020] Techniques relevant to tamper-resistance are 

10 well known to those skilled in the art of security. These 
techniques include methods for resisting tampering 
(such as appropriate encapsulation of the trusted de- 
vice), methods for detecting tampering (such as detec- 
tion of out of specification voltages, X-rays, or loss of 

15 physical integrity in the trusted device casing), and 
methods for eliminating data when tampering is detect- 
ed. Further discussion of appropriate techniques can be 
found at http://www.cl.cam.ac.uk/~mgk25/tamper.html. 
It will be appreciated that, although tamper-proofing is 

20 a most desirable feature of the present invention, it does 
not enter into the normal operation of the invention and, 
as such, is beyond the scope of the present invention 
and will not be described in any detail herein. 
[0021 ] The trusted device is preferably a physical one 

25 because it must be difficult to forge. It is most preferably 
tamper-resistant because it must be hard to counterfeit. 
It typically has an engine capable of using cryptographic 
processes because it is required to prove identity, both 
locally and at a distance, and it contains at least one 

30 method of measuring some integrity metric of the plat- 
form with which it is associated. 
[0022] A trusted platform 10 is illustrated in the dia- 
gram in Figure 6. The platform 10 includes the standard 
features of a keyboard 14, mouse 16 and visual display 

35 unit (VDU) 1 8, which provide the physical 'user interface' 
of the platform. This embodiment of a trusted platform 
also contains a smart card reader 1 2 - a smart card read- 
er is not an essential element of all trusted platforms, 
but is employed in various preferred embodiments de- 

40 scribed below. Along side the smart card reader 12, 
there is illustrated a smart card 19 to allow trusted user 
interaction with the trusted platform (use of a smart card 
for local trusted user interaction with a trusted platform 
is not of general relevance to function of the present in- 

45 vention, although embodiments of the present inven- 
tion, may be used in this context, and is not described 
in detail herein - this aspect is further described in the 
applicant's International Patent Application No. PCT/ 
GB00/00751, entitled "Smartcard User Interface for 

so Trusted Computing Platform", and filed on 3 March 
2000, the contents of which application are incorporated 
by reference herein). In the platform 10, there are a plu- 
rality of modules 1 5: these are other functional elements 
of the trusted platform of essentially any kind appropri- 

55 ate to that platform (the functional significance of such 
elements is not relevant to the present invention and will 
not be discussed further herein). 
[0023] As illustrated in Figure 7, the motherboard 20 
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of the trusted computing platform 10 includes (among 
other standard components) a main processor 21 , main 
memory 22, a trusted device 24, a data bus 26 and re- 
spective control lines 27 and lines 28, BIOS memory 29 
containing the BIOS program for the platform 10 and an 5 
Input/Output (IO) device 23, which controls interaction 
between the components of the motherboard and the 
smart card reader 12, the keyboard 14, the mouse 16 
and the VDU 18. The main memory 22 is typically ran- 
dom access memory (RAM). In operation, the platform io 
10 loads the operating system, for example Windows 
NT™, into RAM from hard disk (not shown). Additionally, 
in operation, the platform 1 0 loads the processes or ap- 
plications that may be executed by the platform 10 into 
RAM from hard disk (not shown). is 
[0024] Typically, in a personal computer the BIOS pro- 
gram is located in a special reserved memory area, the 
upper 64K of the first megabyte do the system memory 
(addresses F000h to FFFFh), and the main processor 
is arranged to look at this memory location first, in ac- 20 
cordance with an industry wide standard. 
[0025] The significant difference between the plat- 
form and a conventional platform is that, after reset, the 
main processor is initially controlled by the trusted de- 
vice, which then hands control over to the platform-spe- 
cific BIOS program, which in turn initialises all input/out- 
put devices as normal. After the BIOS program has ex- 
ecuted, control is handed over as normal by the BIOS 
program to an operating system program, such as Win- 
dows NT (TM), which is typically loaded into main mem- 
ory 22 from a hard disk drive (not shown). 
[0026] Clearly, this change from the normal procedure 
requires a modification to the implementation of the in- 
dustry standard, whereby the main processor 21 is di- 
rected to address the trusted device 24 to receive its first 
instructions. This change may be made simply by hard- 
coding a different address into the main processor 21. 
Alternatively, the trusted device 24 may be assigned the 
standard BIOS program address, in which case there is 
no need to modify the main processor configuration. 
[0027] It is highly desirable for the BIOS boot block to 
be contained within the trusted device 24. This prevents 
subversion of the obtaining of the integrity metric (which 
could otherwise occur if rogue software processes are 
present) and prevents rogue software processes creat- 
ing a situation in which the BIOS (even if correct) fails 
to build the proper environment for the operating sys- 
tem. 

[0028] Although, in the trusted computing platform 
embodiment to be described, the trusted device 24 is a 
single, discrete component, it is envisaged that the func- 
tions of the trusted device 24 may alternatively be split 
into multiple devices on the motherboard, or even inte- 
grated into one or more of the existing standard devices 
of the platform. For example, it is feasible to integrate 
one or more of the functions of the trusted device into 
the main processor itself, provided that the functions 
and their communications cannot be subverted. This, 



however, would probably require separate leads on the 
processor for sole use by the trusted functions. Addi- 
tionally or alternatively, although in the present embod- 
iment the trusted device is a hardware device that is 
adapted for integration into the motherboard 20, it is an- 
ticipated that a trusted device may be implemented as 
a 'removable' device, such as a dongle, which could be 
attached to a platform when required. Whether the trust- 
ed device is integrated or removable is a matter of de- 
sign choice. However, where the trusted device is sep- 
arable, a mechanism for providing a logical binding be- 
tween the trusted device and the platform should be 
present. 

[0029] The trusted device 24 comprises a number of 
blocks, as illustrated in Figure 8. After system reset, the 
trusted device 24 performs a secure boot process to en- 
sure that the operating system of the platform 10 (in- 
cluding the system clock and the display on the monitor) 
is running properly and in a secure manner. During the 
secure boot process, the trusted device 24 acquires an 
integrity metric of the computing platform 1 0. The trust- 
ed device 24 can also perform secure data transfer and, 
for example, authentication between it and a smart card 
via encryption/decryption and signature/verification. 
The trusted device 24 can also securely enforce various 
security control policies, such as locking of the user in- 
terface. In a particularly preferred arrangement, the dis- 
play driver for the computing platform is located within 
the trusted device 24 with the result that a local user can 
trust the display of data provided by the trusted device 
24 to the display - this is further described in the appli- 
cant's International Patent Application No. PCT/ 
GB00/02005, entitled "System for Providing a Trustwor- 
thy User Interface" and filed on 25 May 2000, the con- 
tents of which are incorporated by reference herein. 
[0030] Specifically, the trusted device comprises: a 
controller 30 programmed to control the overall opera- 
tion of the trusted device 24, and interact with the other 
functions on the trusted device 24 and with the other 
devices on the motherboard 20; a measurement func- 
tion 31 for acquiring the integrity metric from the platform 
10; a cryptographic function 32 for signing, encrypting 
or decrypting specified data; an authentication function 

33 for authenticating a smart card; and interface circuitry 

34 having appropriate ports (36, 37 & 38) for connecting 
the trusted device 24 respectively to the data bus 26, 
control lines 27 and address lines 28 of the motherboard 
20. Each of the blocks in the trusted device 24 has ac- 
cess (typically via the controller 30) to appropriate vol- 
atile memory areas 4 and/or non-volatile memory areas 
3 of the trusted device 24. Additionally, the trusted de- 
vice 24 is designed, in a known manner, to be tamper 
resistant. 

[0031 ] For reasons of performance, the trusted device 
24 may be implemented as an application specific inte- 
grated circuit (ASIC). However, for flexibility, the trusted 
device 24 is preferably an appropriately programmed 
microcontroller. Both ASICs and micro-controllers are 
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well known In the art of microelectronics and will not be 
considered herein in any further detail. 
[0032] One item of data stored in the non-volatile 
memory 3 of the trusted device 24 is a certificate 350. 
The certificate 350 contains at least a public key 351 of 
the trusted device 24 and an authenticated value 352 of 
the platform integrity metric measured by a trusted party 
(TP). The certificate 350 is signed by the TP using the 
TP's private key prior to it being stored in the trusted 
device 24. In later communications sessions, a user of 
the platform 1 0 can verify the integrity of the platform 1 0 
by comparing the acquired integrity metric with the au- 
thentic integrity metric 352. If there is a match, the user 
can be confident that the platform 1 0 has not been sub- 
verted. Knowledge of the TP's generally-available pub- 
lic key enables simple verification of the certificate 350. 
The non-volatile memory 35 also contains an identity 
(ID) label 353. The ID label 353 is a conventional ID la- 
bel, for example a serial number, that is unique within 
some context. The ID label 353 is generally used for in- 
dexing and labelling of data relevant to the trusted de- 
vice 24, but is insufficient in itself to prove the identity of 
the platform 10 under trusted conditions. 
[0033] The trusted device 24 is equipped with at least 
one method of reliably measuring or acquiring the integ- 
rity metric of the computing platform 10 with which it is 
associated. In the present embodiment, the integrity 
metric is acquired by the measurement function 31 by 
generating a digest of the BIOS instructions in the BIOS 
memory. Such an acquired integrity metric, if verified as 
described above, gives a potential user of the platform 
10 a high level of confidence that the platform 10 has 
not been subverted at a hardware, or BIOS program, 
level. Other known processes, for example virus check- 
ers, will typically be in place to check that the operating 
system and application program code has not been sub- 
verted. 

[0034] The measurement function 31 has access to: 
non-volatile memory 3 for storing a hash program 354 
and a private key 355 of the trusted device 24, and vol- 
atile memory 4 for storing acquired integrity metric in the 
form of a digest 361. In appropriate embodiments, the 
volatile memory 4 may also be used to store the public 
keys and associated ID labels 360a-360n of one or more 
authentic smart cards 19s that can be used to gain ac- 
cess to the platform 10. 

[0035] In one preferred implementation, as well as the 
digest, the integrity metric includes a Boolean value, 
which is stored in volatile memory 4 by the measure- 
ment function 31 , for reasons that will become apparent. 
[0036] A preferred process for acquiring an integrity 
metric will now be described with reference to Figure 9. 
[0037] In step 500, at switch-on, the measurement 
function 31 monitors the activity of the main processor 
21 on the data, control and address lines (26, 27 & 28) 
to determine whether the trusted device 24 is the first 
memory accessed. Under conventional operation, a 
main processor would first be directed to the BIOS mem- 



ory first in order to execute the BIOS program. However, 
in accordance with the present embodiment, the main 
processor 21 is directed to the trusted device 24, which 
acts as a memory. In step 505, if the trusted device 24 

5 is the first memory accessed, in step 51 0, the measure- 
ment function 31 writes to volatile memory 3 a Boolean 
value which indicates that the trusted device 24 was the 
first memory accessed. Otherwise, in step 515, the 
measurement function writes a Boolean value which in- 

10 dicates that the trusted device 24 was not the first mem- 
ory accessed. 

[0038] In the event the trusted device 24 is not the first 
accessed, there is of course a chance that the trusted 
device 24 will not be accessed at all. This would be the 
15 case, for example, if the main processor 21 were ma- 
nipulated to run the BIOS program first. Under these cir- 
cumstances, the platform would operate, but would be 
unable to verify its integrity on demand, since the integ- 
rity metric would not be available. Further, if the trusted 
20 device 24 were accessed after the BIOS program had 
been accessed, the Boolean value would clearly indi- 
cate lack of integrity of the platform. 
[0039] In step 520, when (or if) accessed as a memory 
by the main processor 21 , the main processor 21 reads 
25 the stored native hash instructions 354 from the meas- 
urement function 31 in step 525. The hash instructions 
354 are passed for processing by the main processor 
21 over the data bus 26. In step 530, main processor 21 
executes the hash instructions 354 and uses them, in 
30 step 535, to compute a digest of the BIOS memory 29, 
by reading the contents of the BIOS memory 29 and 
processing those contents according to the hash pro- 
gram. In step 540, the main processor 21 writes the 
computed digest 361 to the appropriate non-volatile 
35 memory location 4 in the trusted device 24. The meas- 
urement function 31, in step 545, then calls the BIOS 
program in the BIOS memory 29, and execution contin- 
ues in a conventional manner. 
[0040] Clearly, there are a number of different ways 
40 in which the integrity metric may be calculated, depend- 
ing upon the scope of the trust required. The measure- 
ment of the BIOS program's integrity provides a funda- 
mental check on the integrity of a platform's underlying 
processing environment. The integrity metric should be 
45 of such a form that it will enable reasoning about the 
validity of the boot process - the value of the integrity 
metric can be used to verify whether the platform booted 
using the correct BIOS. Optionally, individual functional 
blocks within the BIOS could have their own digest val- 
50 ues, with an ensemble BIOS digest being a digest of 
these individual digests. This enables a policy to state 
which parts of BIOS operation are critical for an intended 
purpose, and which are irrelevant (in which case the in- 
dividual digests must be stored in such a manner that 
55 validity of operation under the policy can be estab- 
lished). 

[0041 ] Other integrity checks could involve establish- 
ing that various other devices, components or apparatus 
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attached to the platform are present and in correct work- 
ing order. In one example, the BIOS programs associ- 
ated with a SCSI controller could be verified to ensure 
communications with peripheral equipment could be 
trusted. In another example, the integrity of other devic- 
es, for example memory devices or co-processors, on 
the platform could be verified by enacting fixed chal- 
lenge/response interactions to ensure consistent re- 
sults. Where the trusted device 24 is a separable com- 
ponent, some such form of interaction is desirable to 
provide an appropriate logical binding between the trust- 
ed device 14 and the platform. Also, although in the 
present embodiment the trusted device 24 utilises the 
data bus as its main means of communication with other 
parts of the platform, it would be feasible, although not 
so convenient, to provide alternative communications 
paths, such as hard-wired paths or optical paths. Fur- 
ther, although in the present embodiment the trusted de- 
vice 24 instructs the main processor 21 to calculate the 
integrity metric in other embodiments, the trusted device 
itself is arranged to measure one or more integrity met- 
rics. 

[0042] Preferably, the BIOS boot process includes 
mechanisms to verify the integrity of the boot process 
itself. Such mechanisms are already known from, for ex- 
ample, Intel's draft "Wired for Management baseline 
specification v 2.0 - BOOT Integrity Service", and in- 
volve calculating digests of software or firmware before 
loading that software or firmware. Such a computed di- 
gest is compared with a value stored in a certificate pro- 
vided by a trusted entity, whose public key is known to 
the BIOS. The software/firmware is then loaded only if 
the computed value matches the expected value from 
the certificate, and the certificate has been proven valid 
by use of the trusted entity's public key. Otherwise, an 
appropriate exception handling routine is invoked. 
[0043] Optionally, after receiving the computed BIOS 
digest, the trusted device 24 may inspect the proper val- 
ue of the BIOS digest in the certificate and not pass con- 
trol to the BIOS if the computed digest does not match 
the proper value. Additionally, or alternatively, the trust- 
ed device 24 may inspect the Boolean value and not 
pass control back to the BIOS if the trusted device 24 
was not the first memory accessed. In either of these 
cases, an appropriate exception handling routine may 
be invoked. 

[0044] Figure 1 0 illustrates the flow of actions by a TP, 
the trusted device 24 incorporated into a platform, and 
a user (of a remote platform) who wants to verify the 
integrity of the trusted platform. It will be appreciated 
that substantially the same steps as are depicted in Fig- 
ure 5 are involved when the user is a local user. In either 
case, the user would typically rely on some form of soft- 
ware application to enact the verification. It would be 
possible to run the software application on the remote 
platform or the trusted platform. However, there is a 
chance that, even on the remote platform, the software 
application could be subverted in some way. Therefore, 



it is anticipated that, for a high level of integrity, the soft- 
ware application would reside on a smart card of the us- 
er, who would insert the smart card into an appropriate 
reader for the purposes of verification. 

5 [0045] At the first instance, a TP, which vouches for 
trusted platforms, will inspect the type of the platform to 
decide whether to vouch for it or not. This will be a matter 
of policy. If all is well, in step 600, the TP measures the 
value of integrity metric of the platform. Then, the TP 

10 generates a certificate, in step 605, for the platform. The 
certificate is generated by the TP by appending the trust- 
ed device's public key, and optionally its ID label, to the 
measured integrity metric, and signing the string with the 
TP's private key. 

15 [0046] The trusted device 24 can subsequently prove 
its identity by using its private key to process some input 
data received from the user and produce output data, 
such that the input/output pair is statistically impossible 
to produce without knowledge of the private key. Hence, 

20 knowledge of the private key forms the basis of identity 
in this case. Clearly, it would be feasible to use symmet- 
ric encryption to form the basis of identity. However, the 
disadvantage of using symmetric encryption is that the 
user would need to share his secret with the trusted de- 

25 vice. Further, as a result of the need to share the secret 
with the user, while symmetric encryption would in prin- ' 
ciple be sufficient to prove identity to the user, it would 
insufficient to prove identity to a third party, who could 
not be entirely sure the verification originated from the T 

30 trusted device or the user. 

[0047] In step 61 0, the trusted device 24 is initialised 
by writing the certificate 350 into the appropriate non- 
volatile memory locations 3 of the trusted device 24. 
This is done, preferably, by secure communication with 

35 the trusted device 24 after it is installed in the mother- 
board 20. The method of writing the certificate to the 
trusted device 24 is analogous to the method used to 
initialise smart cards by writing private keys thereto. The 
secure communications is supported by a 'master key', 

40 known only to the TP, that is written to the trusted device 
(or smart card) during manufacture, and used to enable 
the writing of data to the trusted device 24; writing of 
data to the trusted device 24 without knowledge of the 
master key is not possible. 

45 [0048] At some later point during operation of the plat- 
form, for example when it is switched on or reset, in step 
615, the trusted device 24 acquires and stores the in- 
tegrity metric 361 of the platform. 
[0049] When a user wishes to communicate with the 

50 platform, in step 620, he creates a nonce, such as a ran- 
dom number, and, in step 625, challenges the trusted 
device 24 (the operating system of the platform, or an 
appropriate software application, is arranged to recog- 
nise the challenge and pass it to the trusted device 24, 

55 typically via a BIOS-type call, in an appropriate fashion). 
The nonce is used to protect the user from deception 
caused by replay of old but genuine signatures (called 
a 'replay attack') by untrustworthy platforms. The proc- 
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ess of providing a nonce and verifying the response is 
an example of the well-known 'challenge/response' 
process. 

[0050] In step 630, the trusted device 24 receives the 
challenge and creates an appropriate response. This 
may be a digest of the measured integrity metric and the 
nonce, and optionally its ID label. Then, in step 635, the 
trusted device 24 signs the digest, using its private key, 
and returns the signed digest, accompanied by the cer- 
tificate 350, to the user. 

[0051 ] In step 640, the user receives the challenge re- 
sponse and verifies the certificate using the well known 
public key of the TP. The user then, in step 650, extracts 
the trusted device's 24 public key from the certificate 
and uses it to decrypt the signed digest from the chal- 
lenge response. Then, in step 660, the user verifies the 
nonce inside the challenge response. Next, in step 670, 
the user compares the computed integrity metric, which 
it extracts from the challenge response, with the proper 
platform integrity metric, which it extracts from the cer- 
tificate. If any of the foregoing verification steps fails, in 
steps 645, 655, 665 or 675, the whole process ends in 
step 680 with no further communications taking place. 
[0052] Assuming all is well, in steps 685 and 690, the 
user and the trusted platform use other protocols to set 
up secure communications for other data, where the da- 
ta from the platform is preferably signed by the trusted 
device 24. 

[0053] Further refinements of this verification process 
are possible. It is desirable that the challenger becomes 
aware, through the challenge, both of the value of the 
platform integrity metric and also of the method by which 
it was obtained. Both these pieces of information are de- 
sirable to allow the challenger to make a proper decision 
about the integrity of the platform. The challenger also 
has many different options available - it may accept that 
the integrity metric is recognised as valid in the trusted 
device 24, or may alternatively only accept that the plat- 
form has the relevant level of integrity if the value of the 
integrity metric is equal to a value held by the challenger 
(or may hold there to be different levels of trust in these 
two cases). 

[0054] The description above indicates the general 
structure, purpose, and interaction behaviour of a trust- 
ed computing platform. With reference to Figure 11 , the 
logical architecture of a trusted computing platform us- 
ing a compartmented operating system will be de- 
scribed. 

[0055] The logical architecture shown in Figure 11 
shows a logical division between the normal computer 
platform space 400 and the trusted component space 
401 matching the physical distinction between the trust- 
ed component 24 and the remainder of the computer 
platform. The logical space (user space) 400 comprises 
everything physically present on motherboard 20 of 
computer platform 10 other than trusted component 24: 
logical space (trusted space) 401 comprises everything 
present within the trusted component 24. 



[0056] User space 400 comprises all normal logical 
elements of a user platform, many of which are not 
shown here (as they are of no particular significance to 
the operation of the present invention) or are subsumed 

5 into normal computing environment 420, which is under 
the control of the main operating system of the trusted 
computing platform. The logical space representing nor- 
mal computing environment 420 is taken here to include 
normal drivers, including those necessary to provide 

10 communication with external networks 402 such as the 
internet (in the examples shown this is the route taken 
to communicate with the requestor of a service from the 
trusted platform). Also subsumed here within the normal 
computing environment 420 logical space are the stand- 

15 ard computational functions of the computing platform. 
The other components shown within user space 400 are 
compartments 410. These compartments will be de- 
scribed further below. 

[0057] Trusted space 401 is supported by the proces- 

20 sor and memory within trusted component 24. The trust- 
ed space 401 contains a communications component 
for interacting with compartments 410 and normal com- 
puting environment 420, together with components in- 
ternal to the trusted space 401 . It is desirable that there 

25 be a secure communications path between the normal 
computing environment 420 and the trusted space 401 
(the applicant's copending International Patent Applica- 
tion No. PCT/GB00/00504, filed on 15 February 2000, 
the contents of which are incorporated by reference 

30 herein) - alternative embodiments may include a direct 
connection between trusted space 401 and external net- 
works 402 which does not include the user space 400 - 
in the present arrangement, information that is only to 
be exchanged between the trusted space 401 and a re- 

35 mote user will pass encrypted through user space 400. 
The trusted space 401 also contains: an event logger 
472 for collecting data obtained from different opera- 
tions and providing this data in the form desired by a 
party who wishes to verify the integrity of these opera- 

40 tions; cryptographic functions 474 which are required 
(as described below) in communication out of the trust- 
ed space 401 and in providing records within the trusted 
space 401 (for example, by the event logger 472); pre- 
diction algorithms 476 used to determine whether 

45 logged events conform to what is expected; and a serv- 
ice management function 478 which arranges the per- 
formance of services which are to be performed in a 
trusted manner (it would be possible in alternative em- 
bodiments for service management function to reside in 

so the user space 400, but this would require a larger 
amount of encrypted communication and monitoring of 
the service management function 478 itself - residence 
of the service management function 478 within the trust- 
ed space 401 provides for a simpler solution). Also res- 

55 jdent within the trusted space 401 is a trusted compart- 
ment 460. 

[0058] Compartments 41 0, 460 will now be described 
further. A compartment 410, 460 is an environment con- 
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taining a virtual computing engine 41 1 , 461 wherein the 
actions or privileges of processes running on these vir- 
tual computing engines are restricted. Processes to be 
performed on the computing engine within a compart- 
ment will be performed with a high level of isolation from 
interference and prying by outside influences. Such 
processes are also performed with a high level of re- 
striction on interference or prying by the process on in- 
appropriate data. These properties are the result of the 
degree of reliability, because of the restrictions placed 
on the compartment, even though there is not the same 
degree of protection from outside influence that is pro- 
vided by working in the trusted space 401 . A well known 
form of compartment is a Java sandbox, in which case 
the virtual computing engine 411, 461 is a Java Virtual 
Machine (JVM). Java Virtual Machines and the handling 
of security within Java are described at the Sun Mi- 
crosystems Java web site (http://java.sun.com, particu- 
larly http://java.sun.com/security). To implement sand- 
boxes, a Java platform relies on three major compo- 
nents: the class loader, the byte-code verifier, and the 
security manager. Each component plays a key role in 
maintaining the integrity of the system. Together, these 
components ensure that: only the correct classes are 
loaded; the classes are in the correct format; untrusted 
classes will not execute dangerous instructions; and un- 
trusted classes are not allowed to access protected sys- 
tem resources. Each component is described further in, 
for example, the white paper entitled "Secure Comput- 
ing with Java™: Now and the Future" or in the Java De- 
velopment Kit 1.1.X (both obtainable from Sun Mi- 
crosystems, for example at http://java.sun.com). An ex- 
ample of the use of Java Virtual Machines in a compart- 
mental environment is provided by HP Praesidium Vir- 
tualVault (basic details of HP Praesidium VirtualVault 
are described at http://www.hp.com/security/products/ 
virtualvault/papers/br ief_4.0/). 
[0059] Each compartment thus contains a Java Virtu- 
al Machine 411 ,461 as a computational engine for car- 
rying out a process element (to be assigned to the com- 
partment by the service management process 478, as 
will be described further below). Also contained within 
each compartment 411,461 is a communications tool 
412,462 allowing the compartment to communicate ef- 
fectively with other system elements (and in particular 
with the trusted space 401 by means of communications 
tool 470), a monitoring process 413,463 for logging de- 
tails of the process carried out on the JVM 41 1 ,461 and 
returning details to the event logger 472 in the trusted 
space 401 , and memory 414,464 for holding data need- 
ed by the JVM 411 ,461 for operation as a compartment 
and for use by the process element allocated to the com- 
partment. Note that the functions of the event Jogger 472 
may be modified in respect of embodiments of the 
present invention, as will be discussed further below. 
[0060] There are two types of compartment shown in 
Figure 11. Compartments 410 are provided in the user 
space 400, and are protected only through the inherent 



security of a compartment. Compartments 41 0 are thus 
relatively secure against attack or corruption. However, 
for process elements which are particularly critical or 
particularly private, it may be desirable to insulate the 

5 process element from the user space 400 entirely. This 
can be achieved by locating a "trusted" compartment 
460 within the trusted space 401 - the functionality of 
compartment 460 is otherwise just the same as that of 
compartment 410. An alternative to locating a trusted 

io compartment 460 physically within the trusted device 24 
itself is to locate the trusted compartment 460 within a 
separate physical element physically protected from 
tampering in the same way that trusted device 24 is pro- 
tected - in this case it may also be advantageous to pro- 

15 vide a secure communications path between the trusted 
device 24 and the tamper resistant entity containing the 
secure compartment 460. 

[0061] Trusted compartments 460 provide a higher 
level of trust than components 410 because the "oper- 

20 ating system" and "compartment protections" inside 
trusted module 24 may be hardcoded into hardware or 
firmware, and access to data or processes outside the 
trusted space 401 governed by a hardware or firmware 
gatekeeper. This makes it extremely difficult for a proc- 

25 ess in a trusted compartment to subvert its controls, or 
be affected by undesirable processes. 
[0062] The number of protected compartments 460 
provided is a balance between, on the one hand, the 
amount of highly trusted processing capacity available, 

30 and on the other hand, platform cost and platform per- 
formance. The number of compartments 410 available 
is less likely to affect cost significantly, but is a balance 
between platform performance and the ability to gather 
evidence about executing processes. 

35 [0063] Depending on the complexity of processes to 
be performed by the trusted computing platform, there 
may be any number of compartments 41 0 and trusted 
compartments 460 used in the system. 
[0064] Such a platform may be used as a service plat- 

40 form to perform a service for a requestor, where the re- 
questor requires the service to be performed in a spe- 
cific manner. In particular, the requestor requires certain 
service elements within the overall service to be per- 
formed with a certain degree of reliability or security. 

45 Broadly, the service elements can be divided into three 
categories: service elements that it is essential be trust- 
ed; service elements that are required to be trustworthy, 
and service elements that need to operate properly for 
the service to function , but which do not require a special 

so degree of trust. Services that it is essential must be trust- 
ed include, typically, those used to report on the state of 
the software environment in the trusted computing plat- 
form (this would be satisfied in principle by appropriate 
use of a trusted computing platform as shown in Figures 

55 1 to 5) and also those that will provide evidence of the 
execution of the service. Service elements that may be 
required to be trustworthy are ones where one of the 
parties involved (most likely the requestor) wishes to 
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treat the service element concerned of being of suffi- 
cient importance that some kind of guarantee of its in- 
tegrity is required. An example could be a function that 
is known to be important to a particular community of 
interest (for example, in civil engineering it may be par- 
ticularly important to ensure that certain types of calcu- 
lation, for example in design of loadbearing compo- 
nents, are performed in an accurate and reliable man- 
ner). Other service elements have no specific level of 
trust associated (although some guarantee of reliability 
can be provided simply by use of a trusted computing 
platform to perform the service. 
[0065] Integrity metrics can be used to determine 
whether there has been a failure of trust. Where a par- 
ticular property or facility is to be regarded as trusted, 
the trusted component records an appropriate integrity 
metric. If the integrity metric indicates a failure of trust 
(for example, in different arrangements this may be in- 
dicated by an unknown computing environment, viewing 
of trusted data or an audit of processes acting on trusted 
data in an unauthorised manner. When more than one 
platform is involved, a trusted process may obtain a 
Trusted Computing Platform Alliance (TCPA) (see e.g. 
www.trustedpc.org) integrity response from the other 
platform(s) to determine the presence of an unaccepta- 
ble platform state, and may refuse to communicate with 
that platform while it remains in that state. If one platform 
is involved, trusted data may be locked using the TCPA 
TPM_Seal command to acceptable platform states, so 
that the TPM in the platform refuses to release crypto- 
graphic keys necessary to recover such trusted data. 
[0066] For processes running in a compartment 
(whether in the user space or the trusted space) the 
stages of performance of a process (here described as 
service process for clarity) will now be described. For 
this example, performance of a service process in com- 
partment 410 in Figure 6 will be considered. The com- 
partment contains a JVM as a virtual computing engine 
411 , a communications process 412 to allow exchange 
of data with (in particular) the service management proc- 
ess 478 and the event logging process 472, a monitoring 
process 413 for logging details of the process carried 
out on the JVM 41 1 and (if appropriate) returning details 
to the event logger 472, together with a memory 41 4 for 
holding data needed by the JVM 41 1 . The service proc- 
ess is provided to the compartment through communi- 
cations process 412 and necessary data placed in the 
memory 414. The service process can then be loaded 
on JVM 411 and the monitoring process 413 initiated 
according to the monitoring requirements provided with 
the service process. 

[0067] Optionally, a compartment may be equipped 
for secure communications with the trusted component 
24 (it may, for example, be provided with a cryptographic 
identity and appropriate cryptographic functions). If this 
is done, the process and any data sent with it by the 
service management process may be encrypted for de- 
cryption by the compartment. 



[0068] The constrained nature of the compartment 
environment (in particular, features such as the class 
loader) prevent the loading of code other than that which 
is intended. This allows for secure loading of the service 
5 process onto the JVM 411 . In a preferred modification, 
this approach can be extended to input data used by a 
service process. Preferably, data for use by service 
processes includes use permission information for that 
data (a default could be provided if there is no use per- 
10 mission attached - logically, this would be to allow un- 
limited use). Service processes, particularly those exe- 
cuting in a constrained environment such as a compart- 
ment, can then be adapted such that input data is only 
used if the service process qualifies under the relevant 
is permissions. This may be achieved by typing input data 
to a service process (and logically also output data from 
the service) with labels, and also typing the operations 
performed by the service process upon data. A type la- 
bel may indicate function ("use only in processes con- 
20 nected in searching for insurance policies and in proc- 
esses connected with obtaining approval for a credit 
card application") or operational conditions ("use only in 
processes that execute before a certain time") or both. 
If the intended use of the data by a process is incom- 
es patible with the type label of that data, the data is not 
used by the process and an exception may be raised. 
Typing of input and output data, and of service process 
operations, in this way prevents data misuse. In embod- 
iments of the present invention, as will be discussed fur- 
30 ther below, these ideas are extended to privacy of the 
data itself and its control by the owner of the data, and 
also to auditing of processes acting on such data and 
the privacy of such audit data. 

[0069] When the compartment 410 returns input data 

35 to the process (this may be from memory 414 if the rel- 
evant data was provided by the service management 
process, from the main memory of the computing plat- 
form (or elsewhere) if it is well-known data or if a refer- 
ence to data location has been passed to the service 

40 process, or may even be specifically requested from the 
trusted component 24) the monitoring process 41 3 gen- 
erates, if required, a secure log of the input data (and, 
advantageously, any associated type tag). An effective 
way to do this is discussed further below. 

45 [0070] Input data may be obtained from third parties, 
or may be present locally but have an identified "owner". 
In these cases, it may be desirable for the owner to be 
informed when the owner's data is used as input data in 
a service process - it may also be desirable for the proc- 

50 ess to contact the owner to obtain active consent to its 
use. In addition to input data, it is possible that a service 
process may call other processes or routines which 
could themselves have owners. Again, the compart- 
ment could inform these owners of the use of their proc- 

55 esses or routines. 

[0071 ] When the service process produces output da- 
ta, it writes it to (generally) memory 414 and preferably 
includes with the output data a type of usage permitted 
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on the data. A secure log of the output data may be gen- 
erated in essentially the same way as for input data. 
[0072] At the end of the execution of the service proc- 
ess on the compartment, there are two types of output. 
One is, as normal, the output results of the service proc- 
ess. In addition, there is (if requested by the service 
management process) a log produced by the monitoring 
process 413 which includes one or more of input data, 
output data and process execution data, in any form 
from a complete record of data and instructions to a cal- 
culated value of a sampling process, with different mon- 
itoring processes often used for different types of infor- 
mation. As will be discussed further below, in embodi- 
ments of the invention this use of this log is controlled 
to maintain the privacy of the owner of the data on which 
the service process has acted. 
[0073] Embodiments of the present invention will now 
be further described. The skilled person will appreciate 
that the present invention does not rely for its operation 
on the use of trusted compartments exactly as set out 
in the computer platform of Figure 1 1 ; use of such trust- 
ed compartments is simply one example of how the 
same may be achieved. There will now be described 
how access to third party data, and to audit records for 
processes executing on third party data, may be con- 
trolled by use of an audit data portal as an interface to 
such data operating in accordance with rules provided 
by the third party. Such an arrangement can safeguard 
the third party against interference by a user of the trust- 
ed computer platform and even by its administrator - 
such third party data and audit data can even be made 
effectively invisible to either (in that, say, the adminis- 
trator may be able to work out that data of this type ex- 
ists, but will be unable to access it without revealing to 
the third party that there has been a failure of trust). 
[0074] With reference to Figure 1 , the logical architec- 
ture of a trusted computing platform (TCP) 1 08 including 
an audit data portal engine 1 1 0 is shown. The TCP 1 08 
also includes a Trusted Platform Module (TPM) 116, a 
communication section 118 and runs applications 120 
and 122. 

[0075] The audit data portal engine 1 1 0 is concerned 
with the protection and disclosure of data (inputs and 
outputs, as well as ephemeral states) produced and/or 
used by processes executing in trusted compartments 
1 1 2, 1 1 4 as described above. The credibility of such data 
for audit purposes obviously requires additional at- 
tributes that are stored with the usual value of the data, 
some of such attributes being described herein. In a 
genera! sense the usual value of a particular piece of 
data is simply one attribute of that data. Some combi- 
nations of attributes are better suited to maintaining the 
privacy of processes, and a partitioning of attributes to 
support privacy is disclosed herein. 
[0076] The audit data portal engine 1 1 0 is implement- 
ed to allow the protection and disclosure of particular 
attributes by means of a portal to conventional memory 
1 24. Of course, the audit data portal engine 1 1 0 may be 



integrated with conventional memory 124 to provide en- 
hanced conventional memory. The enhancements may 
be achieved, as described in more detail below, by soft- 
ware methods using existing computing engines and ex- 
5 isting memory, provided the platform has sufficient pro- 
tection. 

[0077] Preferably, the enhancements are implement- 
ed using hardware acceleration 110 that augments ex- 
isting memory 1 24, or using specialised memory that in- 
to eludes hardware acceleration (the combination of 110 
and 124). This augmented or enhanced memory sup- 
ports auditing of the execution and results of the trusted 
platform 108, while maintaining protection and privacy 
for data and processes carried out on that data. The en- 
's gine that controls and maintains and protects audit data 
is called an audit data portal 110, since it is the only 
means of access to audit data. The data is sufficient to 
audit a trusted process, the format of the data is opti- 
mised to protect the privacy of the data, and the access 
20 to the data via the portal serves to protect the data. 
[0078] The audit data portal engine 110 provides ac- 
cess to data involved in audit, where different attributes 
of data have associations derived and/or maintained by 
that portal. Very significantly, the audit data portal 110 
25 controls, partitions and/or bundles the audit data ac- 
cording to a contract or policy (as will be discussed fur- 
ther below), in order to communicate just enough data 
for the intended purpose to maximise the privacy of the 
ensemble of data. Also, the audit data portal engine 1 1 0 
30 enables the communication of permissions and data to 
enable execution of a process using or generating that 
audit data while restricting the inspection of data asso- 
ciated with that process. Furthermore, the audit data 
portal engine allows the automatic selection of inspec- 
35 tion points in a process using that audit data, according 
to a policy or contract dependent upon the supplier of 
the audit data and/or the presence of exceptions gener- 
ated by that process. Still further, the audit data portal 
engine allows the provision of synchronisation informa- 
40 tion that identifies possible inspection points in a proc- 
ess using that audit data. 

[0079] The audit data portal may require permission 
or permissions to release or supply audit data. The audit 
data portal may derive sufficient permissions from a pol- 

45 icy and/or a contract to be able to independently release 
audit data to one or more processes and/or to one or 
more audit viewers. Otherwise, the audit data portal may 
be required by the policy and/or the contract to contact 
an owner of the data and/or an owner of the process 

so and/or an owner of the platform and/or another party be- 
fore releasing audit data to a process requesting access 
to the audit data portal and/or a viewer. Such contact 
may be required to obtain explicit permission or merely 
to report before releasing audit data. Such contact pref- 

55 erably uses cryptographic means to ensure the validity 
and integrity of the contact. 

[0080] An audit memory structure designed to imple- 
ment the audit data memory 124 described herein con- 
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tains the attributes of a single piece of data, including 
its usual value. It is, as shown in Figure 2, possible to 
construct the audit memory structure logically using or- 
dinary memory locations (as in ordinary computing plat- 
forms). The memory structure could be logically built as 
a layered structure at a single address 138, each layer 
140 containing a different attribute of the data at that 
address 1 38, with potentially parallel processes concur- 
rently accessing individual layers 140 at that single ad- 
dress 138. Parallel processing is most practical when 
audited memory uses hardware acceleration, because 
such hardware could permit simultaneous access to in- 
dividual attributes. Each attribute is potentially depend- 
ent on other attributes. Many attributes depend on the 
executing process that is accessing the data described 
by that attribute. 

[0081] To obtain audit data, it is necessary to log the 
execution of processes. General discussion of the re- 
cording of execution processes on a compartmented 
trusted platform will now be described with reference to 
Figure 11. 

[0082] For a process generally, there are three types 
of data relevant to execution of processes: these are in- 
put data, output data and execution data. For satisfac- 
tory audit, the audit data should provide a sufficient 
record of the execution of the process to show that it 
took place successfully and correctly without subver- 
sion. To achieve this, it will generally be the case that 
some measure of reconstruction of the process itself 
and the data involved in that process will be achievable 
from the audit data. It can therefore be expected that 
audit data will be of comparable sensitivity to input data 
and output data itself. 

[0083] For input data in a compartment 41 0, the mon- 
itoring process 413 generates, if required, a secure log 
of the input data (and, advantageously, any associated 
type tag). An effective way to do this is to store all this 
logged data in a linked-list, preferably by appending the 
data to a temporary sequence inside the compartment 
- this will be discussed further below. This data can be 
added to a log describing the process. The monitoring 
process adopted can be essentially similar to the proc- 
ess used by the trusted component 24 to monitor the 
integrity of the trusted computing platform. 
[0084] Similarly, the monitoring process 41 3 can mon- 
itor execution of the service process, most logically by 
noting the value of the instructions and the order in 
which they execute. Use of sampling, as described 
above, may be particularly useful in this aspect of the 
monitoring process to reduce the volume of evidence 
produced or the computational burden in obtaining it. A 
preferred solution is to use a hash algorithm or stream 
cipher initialised with a nonce to produce an irregular 
sample rate. As for input data, the resulting data (includ- 
ing the nonce, the log and the sequence value in the 
irregular sampling case) would eventually be provided 
for signature by the trusted component 24. 
[0085] When the service process produces output da- 



ta, it writes it to (generally) memory 414 and preferably 
includes with the output data a type of usage permitted 
on the data. A secure log of the output data may be gen- 
erated in essentially the same way as for input data. 
5 [0086] As suggested above, input, output and execu- 
tion data could all be sampled by the logging process 
rather than simply recorded. Sampling intervals could 
be explicitly stated in a contract with the provider of the 
input data, or may be determined by a function provided 
10 or referred to in the contract, preferably with a secret 
initial value (perhaps provided under the contract). If 
such a function is used, it is desirable to use a function 
with a large amount of entropy, such as a cryptographic 
hash or cipher (most advantageously a stream cipher, 
*5 as this produces output data at the highest rate). After 
initialization, the function produces a data stream. The 
data stream can then be inspected, and when a partic- 
ular pattern or patterns appear in that output, the data 
is sampled and a digest computed (an exemplary proc- 
ess for logging a sequence of values efficiently is to: (1) 
concatenate the existing value of the sequence (func- 
tion) with the new value to be appended to the se- 
quence; (2) pass the data through a hash algorithm, 
such as SHA-1 (described in National Institute of Stand- 
ards and Technology (NIST), Announcement of Weak- 
ness in the Secure Hash Standard, 1 994) ; and (3) set 
the digest produced by the hash algorithm as the new 
value of the sequence). The smaller the length of the 
pattern, the more frequent the average sample rate. Ev- 
idence of a process can thus be gathered at a lower av- 
erage rate than the baud rate of the data. The use of a 
function with high output entropy (such as a hash or ci- 
pher) with pattern matching on its output provides an 
irregular sampling rate that makes it difficult to predict 
when data will not be sampled. The use of a secret ini- 
tialization value provides a convenient way of express- 
ing an irregular sampling rate as a single value. For log- 
ging program instructions (where the speed of the proc- 
ess may be severely limited by the sampling and logging 
process) it may be desirable to use an ensemble of hash 
engines operating in a predetermined manner or se- 
quence in order to handle a higher baud rate of program 
instructions. 

[0087] The outputs of such logging are audit data 
which, in the present case, is provided to the audit data 
portal 110 which then controls access to the audit data. 
The audit data portal may also be used as a controlled 
way to access any trusted data, such as audit data, re- 
lating to a process executing in a trusted compartment 
and in respect of which a third party has made access 
requirements in respect of specific other, or all other, 
parties (including a user or an administrator of the trust- 
ed computing platform itself). The audit memory 124 
therefore needs to be secure against intrusion. 
[0088] Audit memory 124 preferably consists of data 
structures that are protected against interference and 
inspection, so that the only access to data is via a portal 
110 that controls access to audit memory 124. Protec- 
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tion can be provided by physical means, such as barri- 
ers and physical isolation. Protection can also be pro- 
vided by the use of standard cryptographic techniques 
to provide integrity and confidentiality. Such techniques 
are well understood and need not be described here. It 5 
follows however that the attributes of audit memory in- 
clude a cryptographic key and associated algorithm 
identifier. These are required to support the crypto- 
graphic protection mechanisms. These "cryptographic 
key" attributes require special treatment, in order to 10 
maintain a sufficient level of protection for audit data. 
They may be separately created and/or maintained us- 
ing the TCPA -protected storage" capabilities of the 
trusted platform module (TPM) 116 which provides a 
portal for simple confidential storage of data values - is 
these will be discussed further below. Keys from TCP 
protected storage may be supplied to compartments on 
demand, after the presentation of authorisation. Such 
authorisation data may be presented just once, at the 
start of a session, or every time that an attribute is ac- 
cessed. Different authorisation information may be as- 
sociated with different attributes. 
[0089] When the contents of audit memory are prop- 
erly protected, the contents may be safely transferred 
to normal unprotected memory structures. This may oc- 
cur during normal execution, for example when data is 
swapped to temporarily make space in a resource, or 
when a process has terminated, to provide long term 
storage of audit data. 

[0090] In addition to, or instead of, the form of logging 
evidence discussed above, the attributes of an entry in 
audit memory may include at least some of the following: 

the value of the variable; 
the name on the variable; 
the type of the variable; 

these three values being relevant to the variable itself, 
whereas the following values are relevant to the audit of 
that variable: 

the operation on the variable; 
the time of the operation on the variable; 
the caller(s) that had read/write/modify access to 
the variable; 

the conditions that were satisfied in order to gain 
access to the variable; 

the security rating of a compartment where access 
occurred; 

a signature or signatures by a compartment over at 
least some of the fields; 

the key(s) used by a compartment to perform the 
signature(s); 

a signature or signatures by a TPM over at least 
some of the fields; 

the key(s) used by the TPM to perform the signature 

(s); 

the key(s) used by a compartment to provide confi- 



dentiality for some or all fields. 

the key(s) used by a TPM to provide confidentiality 

for some or all fields. 

[0091 ] A TPM or trusted compartment may be provid- 
ed with new capabilities to act as the audit data portal 
10 for audit memory 24. For example, such a portal 
could automatically store ciphered attributes, recover 
plaintext attributes using the "key" attributes, and supply 
plaintext attributes to its host compartment and supply 
ciphertext attributes to other compartments. In its host 
compartment, the portal 10 presents a normal memory 
interface for the storage "value" of data, and automati- 
cally obtains/derives/stores other attributes in associa- 
tion with the "value" attribute. Most attributes such as 
"type", "time", "security attribute" are part of the execu- 
tion information being gathered by the executing com- 
partment 12, 14, for example, and would be automati- 
cally gathered and stored by the portal ! 0 when a "val- 
ue" attribute is stored. 

[0092] In the normal scope of activities on a comput- 
ing platform, it may be necessary for a party to inspect 
the execution of a trusted process. It may also be nec- 
essary to execute or access records of an entire process 
in order to initialise the conditions of interest to a party, 
but it is generally undesirable for that party to have ac- 
cess to the entire process and to inspect all data - this 
may apply even if that party is the user or administrator 
of the trusted computing platform. Consequently, the da- 
ta in audit memory 124 is preferably partitioned into sets 
in order to provide privacy for the data. A set simplifies 
access to the attributes described by that set. The sets 
may be organised according to a policy or contract as- 
sociated with the data or process. One set may provide 
access to all attributes of all data in some time period, 
while another set may provide access to selected at- 
tributes of one data parameter for the entire process for 
example. The portal 110 would store and verify the au- 
thorisation information needed to access attributes and 
sets. Preferably, the portal generates that authorisation 
information. Each set is secured as a set by crypto- 
graphic means, which means are well known in the art 
and need not be described. 

[0093] The partitioning into sets provides privacy 
whilst enabling the tracing of programs for reasons of 
efficiency and/or incorrect execution, or the review of an 
archived process. Partitioning requires different access 
controls and/or different cryptographic keys for different 
attributes of the same data and for a given attribute at 
different times and for a given attribute during the oc- 
currence of given events, for example. If this is done, 
then an audit viewer can be given the access authori- 
sation data or cryptographic keys for only the attributes 
during the period of execution that must be revealed to 
the viewer. It may be sufficient to display just certain at- 
tributes and not others. It may be sufficient to display 
just the caller-to-data and the time-of-access to data, 
but not the value of the data itself, for example. 
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[0094] As indicated above, the partitioning of the audit 
data into sets advantageously provides privacy whilst 
enabling the tracing of programs. This is useful for op- 
timisation of computing resources and for investigation 
of programs that are executing wrongly, for example, 
while maintaining privacy of both the program and the 
data upon which the program operates. 
[0095] The sets may be organised according to a pol- 
icy or contract with a party associated with the data or 
a process requiring auditing. A first set may provide ac- 
cess to all audit data for a specified time period, for ex- 
ample. A second set may provide access to a subset of 
the audit data for the duration of a given process, for 
example. A third set may provide access to a subset of 
the audit data in the presence of certain events, for ex- 
ample. 

[0096] The audit portal may also control access to da- 
ta that may never be directly viewed. This occurs when 
auditing requires supporting data in order to interpret 
viewable data. Such hidden data describes the meaning 
and representation of the viewable data, for example. 
[0097] It should be noted that the audit portal is thus 
effective not only to control access to audit data, but also 
to third party data itself. In accordance with the require- 
ments of the third party, such data can thus be main- 
tained private to the third party - even private from the 
administrator or the user of the trusted computing plat- 
form - or they could be allowed only restricted access 
(perhaps limited access to audit data and no access to 
the third party data itself). When kept private from the 
administrator, say, such data could be effectively invis- 
ible to the administrator (the administrator may be aware 
of the existence of data of this type, but have effectively 
no knowledge of its content). 

[0098] The audit viewer preferably exists in a different 
entity (compartment and/or trusted compartment and/or 
TPM and/or platform) to that executing a process and/ 
or executing the audit portal. In any event, the protec- 
tions of the entity providing the audit viewer must be suf- 
ficient to prevent unauthorised viewing. Only the neces- 
sary attributes for the necessary time should be availa- 
ble to the viewer. The rest of the execution or processing 
should be in an environment to which the viewing party 
does not have access. If they need to communicate, the 
hidden environment and the viewer environment should 
communicate without revealing information to the view- 
ing party. These environments can be implemented us- 
ing the compartments described above. 
[0099] Whereas this describes a preferred arrange- 
ment, the audit data portal may exist in the same or dif- 
ferent entity, which entity may be a compartment and/or 
a trusted compartment and/or a TPM and/or a platform, 
as the process that uses and/or generates the audit da- 
ta. The audit data portal may exist in the same or differ- 
ent entity, which entity may be a compartment and/or a 
trusted compartment and/or a TPM and/or a platform, 
as the computer memory. 

[01 00] Where an audit viewer is provided, this may be 



present in a compartment and/or a trusted compartment 
and/or a TPM. The audit viewer may exist in the same 
entity, which may be a compartment and/or a trusted 
compartment and/or a TPM and/or a platform, as the 

5 audit data portal and/or a process that uses and/or gen- 
erates the audit data and/or the computer memory. 
[0101] If the audit data portal executes in a different 
entity to that of a process processing the audit data, the 
communication of audit data between the audit data por- 

10 tal and the process is preferably protected by physical 
means, which may be physical barriers and/or logical 
means which may be cryptographic methods, that pref- 
erably render the audit data secure and confidential 
while in transit between the audit data portal and the 

15 process. 

[0102] If the audit data portal executes in a different 
entity to that of the audit viewer, the communication of 
audit data between the audit data portal and the viewer 
is preferably protected by physical means, which may 
be physical barriers, and/or logical means, which may 
be cryptographic methods, that render the audit data se- 
cure and confidential while in transit between the audit 
data portal and the viewer. 

[01 03] If a process is executing it may execute on dif- 
ferent processors using conventional remote procedure 
calls (RPC) with enhanced RPC stubs, as is known in 
the art. Most of the process could execute on one plat- 
form, and the audit viewer could execute on a second 
platform, for example. Alternatively, a process may ex- 
ecute in at least two compartments 12, 14 on the same 
platform, some of which compartments execute the hid- 
den part of the process and are not therefore visible to 
the party, and others of which compartments execute 
the part that is to be examined by the party and are 
therefore visible to the party. 

[01 04] In the above, it has been indicated that the ac- 
cess control requirements for third party data and for au- 
dit records of processes carried out in third party data 
may be specified by a contract with the third party. Fig- 
ure 12 illustrates the main elements of a process in by 
which a requestor arranges for a service to be per- 
formed on a service platform as shown in Figure 6 - the 
requestor may for example be a third party owning data, 
and the service platform may be a trusted computer plat- 
form with an audit data portal as described above. 
[0105] The initial step is for the requestor to verify that 
the computing platform is a trusted computing platform 
by authenticating the trusted component 24 in step 701 
- this process is essentially that shown in Figure 1 0. This 
process may be one of mutual authentication - the trust- 
ed computing platform may require that the requestor 
also be a trusted computing platform before performing 
certain kinds of service. 

[0106] In step 702, the requestor sends the material 
necessary to define the service to the trusted computing 
platform. There are two elements to this material: one 
is the "contract", defining the service to be performed 
and any conditions on the performance of the service 
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(such as access control requirements on data or audit 
records), and the other is any custom data required for 
the performance of the service (data which the reques- 
tor does not already know is available to the trusted 
computing platform, typically) - this may be the third par- 5 
ty data for which privacy is required. This material is sent 
in encrypted form for decryption using the cryptographic 
functions of the trusted component 24, or using crypto- 
graphic functions available elsewhere in the computing 
platform, preferably in cooperation with facilities (such 
as key storage or session key communication) provided 
by the trusted component 24. Typically, the requestor 
secures the material under a session key, and then se- 
cures that session key under a key known only to trusted 
component 24. The requestor sends the protected ses- 
sion key and the protected material to the trusted com- 
puting platform. The trusted component 24 (specifically, 
its cryptographic functions 474) recovers the session 
key and verifies the source and integrity of the material 
by conventional security methods. 
[0107] The contract must specify the service suffi- 
ciently that the trusted computing platform can interpret 
how to perform the service - what service elements must 
be performed, and how they are to be combined so that 
the results of the service can be returned to the reques- 
tor (or possibly forwarded to a third party). Moreover, the 
contract will specify any conditions placed by the re- 
questor on how the service as a whole, or individual 
service elements, should be performed. Of particular 
relevance to embodiments of the present invention are 
requirements relating to privacy and access control. 
Such requirements can also relate to trust - for example, 
the requestor may require absolute trust to be essential 
for a first set of processes, high trust to be required for 
a second set of processes, and no specific requirement 
for a third set of processes: these requirements may be 
met by carrying out the first set of processes in trusted 
compartments 460, the second set of processes in com- 
partments 410, and the third set of processes can be 
performed in the normal computing environment 420 
under the control of the operating system of the com- 
puting platform. The requestor may also require evi- 
dence of the performance of the contract, both that the 
contract has been performed reliably but also under the 
conditions of trust required - typically, this requirement 
also needs absolute trust, and requires use of the trust- 
ed component 24, either in providing a trusted compart- 
ment or in providing evidence that normal compart- 
ments are executing in a safe environment. As has been 
described, evidence can be provided by logging inputs, 
execution and outputs of processes, particularly those 
to be carried out in a compartment or a trusted compart- 
ment. As has also been indicated above, evidence of 
this type can be provided as audit data to parties other 
than the third party in an appropriately controlled man- 
ner through the audit data portal. 
[0108] More specifically, a contract will normally in- 
clude the following: the processes that constitute at least 



a part of the service (it may be that other parts of the 
whole service offering are to be performed elsewhere, 
or that the whole service is covered by a "master con- 
tract" to which the present contract is ancillary); any 
processes that must execute on a trusted computing 
platform (typically, the requirement may be that all proc- 
esses execute on a trusted computing platform, but not 
all within compartments or trusted compartments); the 
order of the processes in the service; and an unambig- 
uous description of the processes (names or sources), 
possibly together with data to verify the integrity of such 
a description (such as a signed digest of a program for 
performing the process). The contract may also specify 
trust levels, or may specifically indicate that particular 
processes should be executed within a compartment or 
a trusted compartment. The contract may also deter- 
mine how integrity of processes is determined: whether 
inputs and outputs are recorded or perhaps sampled (if 
so, how they are sampled), and may even determine 
scheduling of aspects of processes: how execution of 
processes is sampled; how execution within compart- 
ments (or trusted compartments) itself occurs; and how 
processes are swapped in and out of compartments (or 
trusted compartments). In embodiments of the present 
invention, the contract may specify access control re- 
quirements for any third party data, and also for any au- 
dit records from logging of processes carried out on 
such third party data. All this information should be pro- 
vided in a machine-readable format for interpretation by 
the trusted computing platform (more specifically, the 
service management process 478) - a programming 
method such as ASN.1 is one possibility. 
[01 09] In step 703, the trusted computing platform ei- 
ther accepts or rejects the contract offer. An offer may 
be rejected if the trusted computing platform does not 
have the configuration required to perform the service 
according to the contract requirements (for example, if 
it does not have trusted compartments available, and 
these are explicitly or implicitly required by the contract 
offer), if the trusted computing platform does not trust 
the requestor, or if the service falls outside other param- 
eters of acceptance programmed into the trusted com- 
puting platform. If an appropriate protocol exists, it may 
be possible to negotiate contract offers at this phase 
(perhaps by the trusted computing platform indicating 
which contract terms it cannot meet and offering alter- 
natives, and the requestor deciding whether the alter- 
natives are acceptable or offering new alternatives of its 
own - the process iterating until a contract is agreed or 
an impasse is reached). 

[01 1 0] If the contract offer is accepted, the service can 
be performed as the trusted computing platform re- 
ceived all necessary information with the contract offer 
(in an alternative, the custom data may be retained until 
the trusted computing platform accepts the contract of- 
fer, and is provided after the acceptance). In step 704, 
the service management process 478 in the trusted 
space 401 partitions the service into processes, and al- 
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locates the processes to trusted compartments 460, 
compartments 41 0 and the operating system 420 as ap- 
propriate. In addition, the service management process 
478 assigns with the allocated processes any monitor- 
ing processes that are necessary to provide perform- 
ance evidence. These may be specified in the contract 
itself, or the service management process 478 may de- 
termine a monitoring process necessary to provide a 
level of evidence required in the contract. In embodi- 
ments of the present invention, audit records will be pro- 
vided through the audit data portal where data privacy 
is required. 

[01 11 ] In step 705, the service (or the processes com- 
prising the service) are performed and the necessary 
evidence logged. In step 706, results of the service are 
provided where they are required (this may be to the 
requestor, or to third parties, or placed in a specific lo- 
cation - this depends on the nature of the service and 
its purpose) and the results of the evidence logging 
process provided to the audit data portal (if privacy is 
required) or to the event logger 472 for assembly into 
evidence for return to the requestor (preferably after sig- 
nature by the trusted component 24). The service evi- 
dence (and, if the results of the service are to be private 
to the requestor, the service results) are then encrypted 
and returned to the requestor in step 707. 
[01 1 2] Examples of the use of such an audit data por- 
tal arrangement will now be discussed. 
[01 1 3] If an application fails when operating on the da- 
ta belonging to a particular customer, that customer 
could send his data to the application vendor for execu- 
tion on the trusted compartment platform 108. A skilled 
customer could manually indicate the point of failure and 
the data and attributes to be examined. This skilled cus- 
tomer instructs the target platform 1 08 to reveal to the 
vendor the stated attributes at the stated time and to 
conceal the rest. A less skilled customer could instruct 
the target platform 108 to automatically reveal certain 
attributes of certain data when the program raises an 
exception, and to conceal the rest of the attributes. In 
both cases the target platform 108 executes the re- 
vealed part in a compartment 112 to which a third party 
has access, and the rest is executed in a compartment 
114 to which the third party does not have access. Al- 
ternatively, the target platform 1 08 executes the process 
in a compartment 114 to which the third party does not 
have access, and transfers execution to a viewer com- 
partment 1 12 when the third party is granted access. Al- 
ternatively, the target platform 1 08 executes the process 
in a compartment 1 1 4 to which the third party does not 
have access, and grants inspection rights to the third 
party when access is granted. 

[01 1 4] In another scenario, a test program executes 
on the customer's trusted compartment platform 108. 
The customer states the attributes whose disclosure is 
permitted. The vendor selects a test program that will 
operate on the customer's platform 108 and report the 
results back to the vendor. The customer verifies the in- 



tegrity of the test program using TCP integrity creden- 
tials, and states the conditions when the test program 
may act as a viewer. 

[0115] It may also be advantageous to provide syn- 
5 chronisation data at the start of each set of attributes. 
Such synchronisation enables a recipient to start an in- 
spection process of part of a process without knowledge 
of the method of interpretation of most of the process. 
The synchronisation method could be common across 
10 most, if not all, processes and could be an advantage 
when inspecting the execution record of a process. The 
sync pattern could be in or out of band. If in-band, it 
could be a pattern that is statistically very unlikely to oc- 
cur. There are very many existing methods of synchro- 
15 nisation and the processes are not described further in 
this document, because examples will be known to the 
person skilled in the art. 

[01 1 6] For clarity, a description will now be given of a 
logical architecture that enables the auditing and view- 
20 ing of trusted processes. 

[01 1 7] Figure 3 illustrates the contents 1 1 04 of audit 
data memory 24. The audit data relevant to process 1 
is stored as the set P1 11 01 . The audit data relevant to 
process 2 is stored as the set P2 1102. The audit data 
25 relevant to process 3 is stored as the set P3 1103. In 
this example, set P1 is disjoint to sets P2 and P3, but 
the data in set P2 overlaps with the data in set P3. 
[0118] Figure 4 illustrates the audit data in set P1 
1101. In this example, process 1 permits three views of 
30 its audit data P1 1101 . The audit data that is visible in 
view 1 is stored as the set P1-V1 1201 . The audit data 
that is visible in view 2 is stored as the set P1-V2 1202. 
The audit data that is visible in view 3 is stored as the 
set P1-V3 1203. Other data, necessary for interpretation 
35 of visible audit data, is hidden and stored as set P1-H1 
1204. 

[0119] Figure 5 illustrates a set of entities that are 
used to gather audit data and examine audit data. A soft- 
ware compartment 1302 executes some processes in- 

40 volved in an application. A software trusted-component 
1303 executes other processes involved in an applica- 
tion. An audit viewer 1 304 executes in a software com- 
partment and enables viewing of the application while it 
executes and/or enables conventional auditing of the 

45 application after it has executed. An audit portal 1305 
executes in a software trusted-compartment. An audit 
memory 1306 resides in normal memory. The compart- 
ments are provided by a compartment operating system 
1301. A Trusted Platform Module 1307 monitors the 

so platform that provides the compartment operating sys- 
tem 1301 and its compartments 1302-1305. The com- 
partment operating system 1301 ensures that the com- 
partments 1 302-1 305 have the necessary isolation from 
each other and from platform resources. The Trusted 

55 Platform Module 1 307 measures the integrity metrics of 
the platform and the compartment operating system 
1301 . The audit portal 1305 uses cryptographic means 
to protect the audit data stored in audit memory 1306. 
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The Trusted Platform Module 1 307 uses TCPA "protect- 
ed storage" functions to store the cryptographic keys 
used by the audit portal 1305 for protecting the audit 
data stored in audit memory 1306. The Trusted Platform 
Module 1307 uses TCPA "protected storage" functions 
to ensure that the cryptographic keys used by the audit 
portal 1305 are not released unless the integrity meas- 
urements of the platform and compartment operating 
system 1 301 indicate that the compartment operating 
system 1301 and its components 1302-1305 are oper- 
ating properly. Thus the TPM 1307 verifies that there 
are: no unauthorised programs executing on the plat- 
form that can snoop on the compartment operating sys- 
tem 1301; the compartment operating system 1301 will 
not snoop or otherwise interfere with the compartments 
1302-1305; and the compartment operating system 
1301 will isolate the compartments 1302-1305. 
[0120] In this example, the system is executing proc- 
ess P1 and using and gathering audit data related to 
process P1 . The process P1 is ready to execute in com- 
partment 1302 and trusted compartment 1303. Audit 
memory 1 306 contains the audit data 1 1 04, but currently 
only ciphertext data P1-V1 1201 exists in set P1 1101. 
Compartment 1302 and trusted compartment 1303 
have normal access to normal data (including pro- 
grams). The audit portal 1305 obtains some crypto- 
graphic keys from the TPM 1307, which releases the 
keys because the integrity metrics indicate that the com- 
partment operating system 1301 and the compartments 
1302-1305 are operating properly, and are not them- 
selves being snooped. The audit portal 1305 fetches ci- 
phertext data P1-V1 1201 from audit memory 1306 and 
decrypts it using the keys fetched from the TPM 1307 
to obtain plaintext data P1-V1 . The audit portal supplies 
the data P1-V1 to compartments 1302 and 1303, which 
execute the application. Those results of the application 
which are required to be audited are sent from the com- 
partments 1302 and 1303 to the audit porta! 1305. The 
audit portal 1305 protects and partitions the results into 
sets P1-V2 1202 and P1-V3 1203 using cryptographic 
means, and stores the ciphertext sets P1-V2 1202 and 
P1-V3 1203 in audit memory 1306. The root crypto key 
for protecting sets P1-V2 1202 and the root crypto key 
for protecting P1-V3 1203 are sent to the TPM 1307. 
The TPM 1307 stores the root keys using TCPA "pro- 
tected storage" functions to ensure that the keys are not 
released unless the integrity measurements of the plat- 
form and compartment operating system 1301 indicate 
that the compartment operating system 1301 and its 
components 1302-1305 are operating properly, and are 
not themselves being snooped. 
[0121] The audit viewer 1304 is given confidentiality 
keys necessary to view audit data P1-V1 and P1-V2. 
These keys and audit data may be specifically released 
by the audit portal 1305 for express use of the audit 
viewer 1304, or may be keys used to communicate the 
sets between the compartments and the audit portal. 
The audit viewer 1 304 may create a viewer of some sort 



that enables a human to interpret the sets P1-V1 1201 
and P1-V2 1202. The audit viewer 1304 may send the 
sets P1-V1 1201 and P1-V2 1202 to another process 
for interpretation, whether by a human or other process. 

5 [0122] The audit data portal described above pro- 
vides significant advantages for the secure and private 
use of data involved in, or relating to the audit of, a proc- 
ess running on a trusted platform, because data is pro- 
vided to parties other than the owner only in accordance 

10 with the wishes of the owner - for example, for specified 
purposes such as auditing only and only to the extent 
necessary for a given auditing reason - by using secure 
compartments in the manner described. 
[0123] Whilst the invention has been described in re- 

15 lation to the applicant's TCP apparatus and the TCPA 
specification, it will be appreciated that the invention 
could be implemented in any trusted environment. In 
this respect a TCP as referred to in the claims is not 
limited to the applicant's trusted computing platform. In 

20 particular, embodiments in accordance with the spirit 
and scope of the present claims can be provided without 
use of a hardware trusted component as described 
herein. 

25 

Claims 

1. A computer platform having: 

30 a trust mechanism adapted to assure third par- 

ties interacting with the computer platform that 
the computer platform operates according to an 
indicated specification; and 

35 a trusted execution area for execution of oper- 

ations upon data, wherein a trusted status of 
the trusted execution area is assured by the 
trust mechanism, and having no uncontrolled 
communication paths with any other part of the 

40 computer platform; 

whereby third party data in a memory of the 
trusted execution area has access restrictions 
to parties other than the third party, and the trust 
45 mechanism is adapted to indicate to the third 

party an attempt to access the third party data 
which is inconsistent with the access restric- 
tions. 

50 2. A computer platform as claimed in claim 1 , wherein 
such access restrictions can comprise no access to 
all or specified parties other than the third party. 

3. A computer platform as claimed in claim 1 or claim 
55 2, wherein the access restrictions apply to a user of 

the computer platform. 

4. A computer platform as claimed in claim 1 or claim 
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2, wherein the access restrictions apply to an ad- 
ministrator of the computer platform. 

5. A computer platform as claimed in any preceding 
claim, wherein the trust mechanism includes a 
hardware trusted component physically and logical- 
ly resistant to unauthorised modification. 

6. A computer platform as claimed in any preceding 
claim, wherein the trusted execution area compris- 
es a compartment provided by an operating system 
of the computer platform. 

7. A computer platform as claimed in claim 6, wherein 
a further compartment is provided as a portal for 
controlled access to third party data and results of 
operations on third party data in the trusted execu- 
tion area. 

8. A computer platform having: 

a trust mechanism adapted to assure third par- 
ties interacting with the computer platform that 
the computer platform operates according to an 
indicated specification; 

a trusted execution area for execution of oper- 
ations upon data, wherein a trusted status of 
the trusted execution area is assured by the 
trust mechanism, and having no uncontrolled 
communication paths with any other part of the 
computer platform; 

an trusted audit mechanism for obtaining an au- 
dit record of operations upon data in the trusted 
execution area and for controlling access to the 
audit record, wherein a trusted status of the 
trusted audit mechanism is assured by the trust 
mechanism. 

9. A computer platform as claimed in claim 8, wherein 
access to the audit record by a user of the computer 
platform is controlled by the trusted audit mecha- 
nism. 

10. A computer platform as claimed in claim 8, wherein 
access to the audit record by an administrator of the 
computer platform is controlled by the trusted audit 
mechanism. 

11. A computer platform as claimed in any of claims 8 
to 1 0, wherein the trust mechanism includes a hard- 
ware trusted component physically and logically re- 
sistant to unauthorised modification. 

12. A computer platform as claimed in any of claims 8 
to 11, wherein the trusted audit mechanism com- 
prises a portal for controlled access to controlled 



data comprising third party data and results of op- 
erations on third party data in the trusted execution 
area. 

5 13. A computer platform as claimed in any of claims 8 
to 12, wherein the trusted execution area comprises 
a compartment provided by an operating system of 
the computer platform. 

w 1 4. A computer platform as claimed in claim 1 3, where- 
in a further compartment is provided as the portal. 

1 5. A computer platform as claimed in claim 1 1 , wherein 
the trusted audit mechanism comprises the hard- 

J5 ware trusted component as a portal for controlled 
access to third party data and results of operations 
on third party data in the trusted execution area. 

1 6. A computer platform as claimed in any of claims 1 2 
20 to 1 5, in which the controlled data is partitioned into 

sets, in order to provide privacy for the controlled 
data by offering the possibility of access to one set 
of the data, or part thereof, without access to anoth- 
er set. 

25 

17. A computer platform as claimed in any of claims 1 2 
to 1 6, further comprising an audit viewer with which 
to view controlled data. 

30 18. An audit data portal for a trusted computing platform 
adapted to assure third parties interacting with the 
computing platform that the computer platform op- 
erates according to an indicated specification is op- 
erable to contain information that is sufficient and/ 
35 or required for the audit of a trusted process exe- 
cuting on the trusted computing platform whose re- 
liable execution is assured by the trusted computing 
platform. 

40 19. An audit data portal as claimed in claim 18, which 
controls access to said information. 

20. An audit data portal for a trusted computing platform 
adapted to assure third parties interacting with the 

45 computing platform that the computer platform op- 
erates according to an indicated specification is op- 
erable to control access to information that is suffi- 
cient and/or required for the audit of a trusted proc- 
ess executing on the trusted computing platform 
50 whose reliable execution is assured by the trusted 
computing platform. 

21. An audit data portal as claimed in claim 20, which 
comprises access control means operable to con- 

55 trol access to a computer memory containing the 
said information. 

22. An audit data portal as claimed in any of claims 18 



25 



30 



35 



40 



45 



18 



35 



EP 1 280 042 A2 



36 



to 21 , which exists within a software compartment, 
such that software executing within that compart- 
ment provides the audit data portal. 

23. An audit data portal as claimed in claim 22, which 
exists within a trusted compartment, such that soft- 
ware executing within the trusted compartment pro- 
vides the audit data portal. 

24. An audit data portal as claimed in claim 22, which 
exists within a trusted platform module which is a 
hardware trusted component physically and logical- 
ly resistant to unauthorised modification, such that 
software and/or firmware and/or hardware of the 
trusted platform module provides the audit data por- 
tal. 

25. An audit data portal as claimed in any of claims 1 8 
to 24, which comprises access control means op- 
erable to control access to a computer memory con- 
taining the said information. 

26. An audit data portal as claimed in any of claims 18 
to 25, wherein the aforesaid information comprises 
audit data and in which the audit data is partitioned 
into sets, in order to provide privacy for the audit 
data by offering the possibility of access to one set 
of the data, or part thereof, without access to anoth- 
er set. 

27. An audit data portal as claimed in any of claims 18 
to 26, wherein the aforesaid information comprises 
audit data and further comprising an audit viewer 
with which to view audit data. 

28. An audit data portal as claimed in any of claims 1 8 
to 27, wherein the aforesaid information comprises 
audit data and in which, where the audit data portal 
executes in a different entity to that of a process 
processing the audit data, the communication of au- 
dit data between the audit data portal and the proc- 
ess is protected. 

29. An audit data portal as claimed in any of claims 18 
to 28, wherein the aforesaid information comprises 
audit data and in which, where the audit data portal 
executes in a different entity to that of the audit view- 
er, the communication of audit data between the au- 
dit data portal and the viewer is protected. 

30. A method of executing operations on third party da- 
ta on a computing platform, the computer platform 
having a trust mechanism adapted to assure third 
parties interacting with the computer platform that 
the computer platform operates according to an in- 
dicated specification, the method comprising: 

providing the data, and third party access re- 



strictions applying to the data, to a trusted ex- 
ecution area having no uncontrolled communi- 
cation paths with any other part of the computer 
platform, wherein a trusted status of the trusted 
5 execution area is assured by the trust mecha- 

nism; 

performing operations on the data in the trusted 
execution area; and 

the trust mechanism indicating to the third party 
10 any attempt to access the third party data which 

is inconsistent with the access restrictions. 

31. A method as claimed in claim 30, wherein the third 
party access restrictions also apply to results of op- 

15 erations on the data in the trusted execution area. 

32. A method as claimed in claim 30 or claim 31 , where- 
in such access restrictions comprise no visibility of 
the data to all or specified parties other than the third 

20 party. 

33. A method as claimed in claim 32, wherein the all or 
specified parties include a user of the computer 
platform. 

25 

34. A method as claimed in claim 32, wherein the all or 
specified parties include an administrator of the 
computer platform. 

30 35. a method of auditing of operations on third party da- 
ta on a computing platform, the computer platform 
having a trust mechanism adapted to assure third 
parties interacting with the computer platform that 
the computer platform operates according to an in- 

35 dicated specification, the method comprising: 

providing the data to a trusted execution area 
having no uncontrolled communication paths 
with any other part of the computer platform, 
40 wherein a trusted status of the trusted execu- 

tion area is assured by the trust mechanism; 
performing operations on the data in the trusted 
execution area; 

a trusted audit mechanism obtaining an audit 
45 record of operations upon data in the trusted 

execution area, wherein a trusted status of the 
trusted audit mechanism is assured by the trust 
mechanism; and 

the trusted audit mechanism providing control- 
so led access to the audit record. 

36. A method as claimed in claim 35, wherein access 
to the audit record by a user of the computer plat- 
form is controlled by the trusted audit mechanism. 

55 

37. A method as claimed in claim 35, wherein access to 
the audit record by an administrator of the computer 
platform is controlled by the trusted audit mechanism. 
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